当前位置: 开发笔记 > 编程语言 > 正文

可能会|侧面_关于AndroidUI绘制优化你应该了解的知识点

作者： | 来源：互联网 | 2023-06-26 21:04

篇首语：本文由编程笔记#小编为大家整理，主要介绍了关于AndroidUI绘制优化你应该了解的知识点相关的知识，希望对你有一定的参考价值。一、

篇首语：本文由编程笔记#小编为大家整理，主要介绍了关于Android UI绘制优化你应该了解的知识点相关的知识，希望对你有一定的参考价值。

一、android绘制原理及工具选择

1.1、Android绘制原理

对于Android手机来说&＃xff0c;它的画面渲染依赖于两个硬件&＃xff1a;1.CPU&＃xff1b;2.GPU&＃xff1a;

CPU负责计算显示内容&＃xff0c;比如&＃xff1a;视图创建、布局计算、图片解码、文本绘制等
GPU负责栅格化&＃xff08;UI元素绘制到屏幕上&＃xff09;&＃xff0c;栅格化&＃xff1a;将一些组件比如Button、Bitmap拆分成不同的像素进行显示然后完成绘制&＃xff0c;这个操作相对比较耗时&＃xff0c;所以引入GPU来加快栅格化操作
16ms发出VSync信号触发UI渲染&＃xff0c;意思就是Android系统要求每一帧都要在16ms内完成&＃xff0c;具体到项目中就是不管业务代码或者其他逻辑代码有多复杂&＃xff0c;想要保证每一帧都很平滑&＃xff0c;渲染代码就应该在16ms内完成
大多数的Android设备屏幕刷新频率&＃xff1a;60Hz &＃xff0c;60帧/秒是人眼和大脑之间协作的极限

1.2、优化工具

1.Systrace

关注Frames
正常&＃xff1a;绿色圆点&＃xff0c;丢帧&＃xff1a;黄色或红色
Alerts&＃xff1a;Systrace中自动分析并且标注异常性能的条目

上面这张图是我找的一个使用Systrace生成的.html文件&＃xff0c;图中每一个F的出现就表明出现了一帧&＃xff0c;可以看到这两个F之间的时间间隔比16ms多了不少&＃xff0c;Alert type这里面就是Systrace自动给出的一些提示信息&＃xff0c;我们可以根据提示信息来查找修改的方向。

②、Layout Inspector

菜单栏——>Tools——>Layout Inspector

Android Studio自带的工具
查看试图层次结构

③、Choreographer

获取FPS&＃xff0c;线上使用&＃xff0c;具备实时性

Api 16之后
使用方式是&＃xff1a;Choreographer.getInstance().postFrameCallback

这里写了一个方法getFPS()来获取这个APP的FPS情况&＃xff0c;方法内部一开始是做了一个保护性操作&＃xff0c;确保使用的Choreographer发生在API16之后&＃xff0c;然后在doFrame回调中首先判断是不是统计周期的第一次&＃xff0c;如果是就记录第一次回调的时间&＃xff0c;接下来就是判断时间间隔是否超过预设的阀值160ms&＃xff0c;如果超过则计算FPS&＃xff0c;计算方式是间隔时间除以间隔时间内发生的次数&＃xff0c;如果没有超过则直接将次数加1。

输出的结果可以看到基本上都是59和60之间的数值。

二、Android布局加载原理

2.1、布局加载流程

1.源码解析

这一部分我们来看下源码&＃xff0c;因为内容比较多&＃xff0c;我就尽可能的简单说&＃xff0c;对于源码阅读的流程我们之前已经说过几次了&＃xff0c;这里就不再介绍了&＃xff0c;基本上就是找到你需要的入口方法&＃xff0c;然后一路跟踪下去&＃xff0c;把整个流程串起来&＃xff0c;不需要你把每一行的代码都读懂。

既然说的是布局加载&＃xff0c;那么我们首先肯定是找入口方法&＃xff0c;这个方法你回想一下每个页面加载布局都是调用的什么方法呢&＃xff1f;很简单啦&＃xff1a;

setContentView(R.layout.activity_main);

然后点击这个方法进入源码中去就到了AppCompatActivity类的setContentView()方法中&＃xff1a;

&＃64;Override public void setContentView(&＃64;LayoutRes int layoutResID) getDelegate().setContentView(layoutResID);

继续跟踪点击setContentView()方法&＃xff1a;

发现这是一个抽象方法&＃xff0c;此时你需要去找它的实现类AppCompatDelegateImpl中的方法了&＃xff0c;点击左侧向下的fx向下箭头&＃xff1a;

&＃64;Override public void setContentView(int resId) ensureSubDecor(); ViewGroup contentParent &＃61; mSubDecor.findViewById(android.R.id.content); contentParent.removeAllViews(); LayoutInflater.from(mContext).inflate(resId, contentParent); mAppCompatWindowCallback.getWrapped().onContentChanged();

这个方法中由于传递进来的resId也就是布局文件的id&＃xff0c;它只在LayoutInflater这一行用到了&＃xff0c;所以接着跟踪这一行&＃xff0c;点击inflate()方法&＃xff1a;

public View inflate(&＃64;LayoutRes int resource, &＃64;Nullable ViewGroup root) return inflate(resource, root, root !&＃61; null);

这个方法内部又调用了另一个inflate()方法&＃xff0c;所以继续点击&＃xff1a;

public View inflate(&＃64;LayoutRes int resource, &＃64;Nullable ViewGroup root, boolean attachToRoot) final Resources res &＃61; getContext().getResources(); if (DEBUG) Log.d(TAG, "INFLATING from resource: \\"" &＃43; res.getResourceName(resource) &＃43; "\\" (" &＃43; Integer.toHexString(resource) &＃43; ")"); View view &＃61; tryInflatePrecompiled(resource, res, root, attachToRoot); if (view !&＃61; null) return view; XmlResourceParser parser &＃61; res.getLayout(resource); try return inflate(parser, root, attachToRoot); finally parser.close();

这里面又有一个inflate()方法&＃xff0c;入参有一个parser&＃xff0c;看了看上下的代码&＃xff0c;知道了它其实是XmlResourceParser的实例&＃xff0c;那我们先不去看这个inflate()方法具体的实现&＃xff0c;先来看下这个parser究竟是什么&＃xff1f;找到res.getLayout()方法&＃xff0c;里面传入了我们的资源id&＃xff0c;返回的是XmlResourceParser&＃xff0c;看名字XML资源解析器&＃xff0c;就知道这玩意应该很屌&＃xff0c;来吧&＃xff0c;继续点击getLayout()&＃xff1a;

&＃64;NonNull public XmlResourceParser getLayout(&＃64;LayoutRes int id) throws NotFoundException return loadXmlResourceParser(id, "layout");

没啥实质性的内容&＃xff0c;继续点击它的实现方法loadXmlResourceParser()&＃xff1a;

&＃64;NonNull &＃64;UnsupportedAppUsage XmlResourceParser loadXmlResourceParser(&＃64;AnyRes int id, &＃64;NonNull String type) throws NotFoundException final TypedValue value &＃61; obtainTempTypedValue(); try final ResourcesImpl impl &＃61; mResourcesImpl; impl.getValue(id, value, true); if (value.type &＃61;&＃61; TypedValue.TYPE_STRING) return impl.loadXmlResourceParser(value.string.toString(), id, value.assetCOOKIE, type); throw new NotFoundException("Resource ID #0x" &＃43; Integer.toHexString(id) &＃43; " type #0x" &＃43; Integer.toHexString(value.type) &＃43; " is not valid"); finally releaseTempTypedValue(value);

这个方法开始是一些对象的声明&＃xff0c;后面是异常的处理&＃xff0c;所以看下来真正有用的就是if判断里面的&＃xff0c;它判断了value.type如果是String类型的&＃xff0c;然后继续调用了impl的loadXmlResourceParser()方法&＃xff0c;我们点进去看下&＃xff1a;

/** * Loads an XML parser for the specified file. * * &＃64;param file the path for the XML file to parse * &＃64;param id the resource identifier for the file * &＃64;param assetCOOKIE the asset COOKIE for the file * &＃64;param type the type of resource (used for logging) * &＃64;return a parser for the specified XML file * &＃64;throws NotFoundException if the file could not be loaded */ &＃64;NonNull XmlResourceParser loadXmlResourceParser(&＃64;NonNull String file, &＃64;AnyRes int id, int assetCOOKIE, &＃64;NonNull String type) throws NotFoundException ... //代码有点多就不贴了&＃xff0c;不然文章会很长&＃xff0c;大家有需要的自己对照这个过程读一下源码&＃xff0c;敬请谅解

主要看注释那里的说明哈&＃xff0c;Android中的布局都是写在XML文件中的&＃xff0c;这个方法就是为我们具体所写的布局文件准备一个XML的解析器&＃xff0c;所以它实际上就是一个XML的Pull解析的过程。需要注意的是&＃xff1a;android的布局实际上是一个XML文件&＃xff0c;它在加载的时候会首先将它读取到内存中&＃xff0c;这个过程实际上就是一个IO过程&＃xff0c;一般在android开发中操作IO都会将其置于工作线程中&＃xff0c;所以这里可能会成为我们优化的一个方向。

关于这个XmlResourceParser就说到这里&＃xff0c;下面继续回到上面说的那个inflate()方法中&＃xff1a;

public View inflate(XmlPullParser parser, &＃64;Nullable ViewGroup root, boolean attachToRoot) synchronized (mConstructorArgs) 。。。 if (TAG_MERGE.equals(name)) if (root &＃61;&＃61; null || !attachToRoot) throw new InflateException(" can be used only with a valid " &＃43; "ViewGroup root and attachToRoot&＃61;true"); rInflate(parser, root, inflaterContext, attrs, false); else // Temp is the root view that was found in the xml final View temp &＃61; createViewFromTag(root, name, inflaterContext, attrs); 。。。。。。 return result;

这里同样的省略了部分代码&＃xff0c;我们知道日常开发中经常会碰到一些报错&＃xff0c;其实这些报错在Android的源码中都是有所体现的&＃xff0c;比如这里定义的关于merge标签的一个异常信息。接着看createViewFromTag()这个方法&＃xff0c;看名字我们应该能大致猜测出来它是干嘛的了&＃xff0c;它应该就是通过一系列的Tag来创建相对应的View&＃xff0c;我们点击该方法跟进&＃xff1a;

&＃64;UnsupportedAppUsage private View createViewFromTag(View parent, String name, Context context, AttributeSet attrs) return createViewFromTag(parent, name, context, attrs, false);

这里面又调用了另一个createViewFromTag()方法&＃xff0c;继续跟进&＃xff1a;

&＃64;UnsupportedAppUsage View createViewFromTag(View parent, String name, Context context, AttributeSet attrs, boolean ignoreThemeAttr) if (name.equals("view")) name &＃61; attrs.getAttributeValue(null, "class"); // Apply a theme wrapper, if allowed and one is specified. if (!ignoreThemeAttr) final TypedArray ta &＃61; context.obtainStyledAttributes(attrs, ATTRS_THEME); final int themeResId &＃61; ta.getResourceId(0, 0); if (themeResId !&＃61; 0) context &＃61; new ContextThemeWrapper(context, themeResId); ta.recycle(); try View view &＃61; tryCreateView(parent, name, context, attrs); if (view &＃61;&＃61; null) final Object lastContext &＃61; mConstructorArgs[0]; mConstructorArgs[0] &＃61; context; try if (-1 &＃61;&＃61; name.indexOf(&＃39;.&＃39;)) view &＃61; onCreateView(context, parent, name, attrs); else view &＃61; createView(context, name, null, attrs); finally mConstructorArgs[0] &＃61; lastContext; return view; catch (InflateException e) throw e; catch (ClassNotFoundException e) final InflateException ie &＃61; new InflateException( getParserStateDescription(context, attrs) &＃43; ": Error inflating class " &＃43; name, e); ie.setStackTrace(EMPTY_STACK_TRACE); throw ie; catch (Exception e) final InflateException ie &＃61; new InflateException( getParserStateDescription(context, attrs) &＃43; ": Error inflating class " &＃43; name, e); ie.setStackTrace(EMPTY_STACK_TRACE); throw ie;

这里就到了重点的地方了&＃xff0c;这里面就是创建View的过程了&＃xff1a;

首先&＃xff1a;View view &＃61; tryCreateView(parent, name, context, attrs); 它通过这个tryCreateView()方法构建出View对象&＃xff0c;进到这个方法中&＃xff1a;

&＃64;UnsupportedAppUsage(trackingBug &＃61; 122360734) &＃64;Nullable public final View tryCreateView(&＃64;Nullable View parent, &＃64;NonNull String name, &＃64;NonNull Context context, &＃64;NonNull AttributeSet attrs) if (name.equals(TAG_1995)) // Let&＃39;s party like it&＃39;s 1995! return new BlinkLayout(context, attrs); View view; if (mFactory2 !&＃61; null) view &＃61; mFactory2.onCreateView(parent, name, context, attrs); else if (mFactory !&＃61; null) view &＃61; mFactory.onCreateView(name, context, attrs); else view &＃61; null; if (view &＃61;&＃61; null && mPrivateFactory !&＃61; null) view &＃61; mPrivateFactory.onCreateView(parent, name, context, attrs); return view;

这个方法里面就是判断了几个factory是否为空
首先是Factory2&＃xff0c;如果Factory2不为空则调用Factory2的onCreateView()方法创建View对象&＃xff0c;否则判断Factory是否为空&＃xff0c;如果Factory不为空则调用Factory的onCreateView()创建View对象&＃xff0c;如果都为空&＃xff0c;则View为空。
如果view为空并且PrivateFactory不为空&＃xff0c;则调用PrivateFactory的onCreateView()方法构建View&＃xff0c;需要注意的是PrivateFactory它只用于Fragment标签的加载。当这些条件都不满足的时候&＃xff0c;我们回到上面的createViewFromTag()方法中接着看&＃xff0c;它会走到view&＃61;&＃61;null的条件判断中去&＃xff0c;它会走onCreateView()或者createView()&＃xff0c;点击createView()继续跟踪&＃xff1a;

&＃64;Nullable public final View createView(&＃64;NonNull Context viewContext, &＃64;NonNull String name, &＃64;Nullable String prefix, &＃64;Nullable AttributeSet attrs) throws ClassNotFoundException, InflateException Objects.requireNonNull(viewContext); Objects.requireNonNull(name); Constructor constructor &＃61; sConstructorMap.get(name); if (constructor !&＃61; null && !verifyClassLoader(constructor)) constructor &＃61; null; sConstructorMap.remove(name); Class clazz &＃61; null; try Trace.traceBegin(Trace.TRACE_TAG_VIEW, name); if (constructor &＃61;&＃61; null) // Class not found in the cache, see if it&＃39;s real, and try to add it clazz &＃61; Class.forName(prefix !&＃61; null ? (prefix &＃43; name) : name, false, mContext.getClassLoader()).asSubclass(View.class); if (mFilter !&＃61; null && clazz !&＃61; null) boolean allowed &＃61; mFilter.onLoadClass(clazz); if (!allowed) failNotAllowed(name, prefix, viewContext, attrs); constructor &＃61; clazz.getConstructor(mConstructorSignature); constructor.setAccessible(true); sConstructorMap.put(name, constructor); else // If we have a filter, apply it to cached constructor if (mFilter !&＃61; null) // Have we seen this name before? Boolean allowedState &＃61; mFilterMap.get(name); if (allowedState &＃61;&＃61; null) // New class -- remember whether it is allowed clazz &＃61; Class.forName(prefix !&＃61; null ? (prefix &＃43; name) : name, false, mContext.getClassLoader()).asSubclass(View.class); boolean allowed &＃61; clazz !&＃61; null && mFilter.onLoadClass(clazz); mFilterMap.put(name, allowed); if (!allowed) failNotAllowed(name, prefix, viewContext, attrs); else if (allowedState.equals(Boolean.FALSE)) failNotAllowed(name, prefix, viewContext, attrs); Object lastContext &＃61; mConstructorArgs[0]; mConstructorArgs[0] &＃61; viewContext; Object[] args &＃61; mConstructorArgs; args[1] &＃61; attrs; try final View view &＃61; constructor.newInstance(args); if (view instanceof ViewStub) // Use the same context when inflating ViewStub later. final ViewStub viewStub &＃61; (ViewStub) view; viewStub.setLayoutInflater(cloneInContext((Context) args[0])); return view; finally mConstructorArgs[0] &＃61; lastContext; 。。。

这个方法里面constructor &＃61; clazz.getConstructor(mConstructorSignature); constructor.setAccessible(true); 这两行首先找到clazz的构造方法&＃xff0c;通过反射的方式将其设置为外部可调用的&＃xff0c;然后下面final View view &＃61; constructor.newInstance(args); 这一行它通过构造函数反射创建了View&＃xff0c;在这个方法中是真正进行了View的创建&＃xff0c;当然这是在没有使用Factory的情况下哦。这个过程实际上它是使用了反射&＃xff0c;反射是有可能导致程序变慢的一个因素&＃xff0c;所以这里也可以作为我们的一个优化点。

2.布局加载流程总结

2.2、性能瓶颈

布局文件解析&＃xff1a;IO过程&＃xff08;文件过大时可能会导致卡顿&＃xff09;
创建View对象&＃xff1a;反射&＃xff08;使用过多也会导致变慢&＃xff09;

2.3、LayoutInflater.Factory

在上面解读setContentView的源码时&＃xff0c;我们知道创建View的过程优先是使用Factory2和Factory进行创建&＃xff0c;下面对这两个类作简要说明&＃xff1a;

LayoutInflater.Factory&＃xff1a;

LayoutInflater创建View的一个Hook&＃xff0c;Hook其实就是我们可以将自己的代码挂在它的原始代码之上&＃xff0c;可以对它的流程进行更改
定制创建View的过程&＃xff1a;比如全局替换自定义TextView等

Factory与Factory2

Factory2继承于Factory
多了一个参数&＃xff1a;parent

我们来看一下它们的源码&＃xff0c;首先来看Factory2&＃xff1a;

public interface Factory2 extends Factory &＃64;Nullable View onCreateView(&＃64;Nullable View parent, &＃64;NonNull String name, &＃64;NonNull Context context, &＃64;NonNull AttributeSet attrs);

可以看到Factory2是一个接口&＃xff0c;并且它是继承自Factory的&＃xff0c;来看一下Factory&＃xff1a;

public interface Factory /** * Hook you can supply that is called when inflating from a LayoutInflater. * You can use this to customize the tag names available in your XML * layout files. * *

* Note that it is good practice to prefix these custom names with your * package (i.e., com.coolcompany.apps) to avoid conflicts with system * names. * * &＃64;param name Tag name to be inflated. * &＃64;param context The context the view is being created in. * &＃64;param attrs Inflation attributes as specified in XML file. * * &＃64;return View Newly created view. Return null for the default * behavior. */ &＃64;Nullable View onCreateView(&＃64;NonNull String name, &＃64;NonNull Context context, &＃64;NonNull AttributeSet attrs);

入参中有个name&＃xff0c;来看一下它的注释&＃xff0c;意思就是我们要加载的Tag&＃xff0c;比如这个Tag是TextView&＃xff0c;那么通过这个方法返回的就是TextView&＃xff0c;实际上如果你继续跟踪的话&＃xff0c;你会发现这个Tag实际上就是我们平时在布局中写的一个个的控件&＃xff1a;比如TextView、ImageView等等&＃xff0c;它会根据具体的Tag来进行对应View的创建&＃xff1a;

switch (name) case "TextView": view &＃61; createTextView(context, attrs); verifyNotNull(view, name); break; case "ImageView": view &＃61; createImageView(context, attrs); verifyNotNull(view, name); break; case "Button": view &＃61; createButton(context, attrs); verifyNotNull(view, name); break; case "EditText": view &＃61; createEditText(context, attrs); verifyNotNull(view, name); break; case "Spinner": view &＃61; createSpinner(context, attrs); verifyNotNull(view, name); break; case "ImageButton": view &＃61; createImageButton(context, attrs); verifyNotNull(view, name); break; case "CheckBox": view &＃61; createCheckBox(context, attrs); verifyNotNull(view, name); break; case "RadioButton": view &＃61; createRadioButton(context, attrs); verifyNotNull(view, name); break; case "CheckedTextView": view &＃61; createCheckedTextView(context, attrs); verifyNotNull(view, name); break; case "AutoCompleteTextView": view &＃61; createAutoCompleteTextView(context, attrs); verifyNotNull(view, name); break; case "MultiAutoCompleteTextView": view &＃61; createMultiAutoCompleteTextView(context, attrs); verifyNotNull(view, name); break; case "RatingBar": view &＃61; createRatingBar(context, attrs); verifyNotNull(view, name); break; case "SeekBar": view &＃61; createSeekBar(context, attrs); verifyNotNull(view, name); break; case "ToggleButton": view &＃61; createToggleButton(context, attrs); verifyNotNull(view, name); break; default: // The fallback that allows extending class to take over view inflation // for other tags. Note that we don&＃39;t check that the result is not-null. // That allows the custom inflater path to fall back on the default one // later in this method. view &＃61; createView(context, name, attrs);

并且我们对比两个接口&＃xff0c;可以发现Factory2比Factory就是入参多了一个parent&＃xff0c;这个parent就是你创建的View的parent&＃xff0c;所以综上可得Factory2比Factory功能上更加强大。

三、优雅获取界面布局耗时

随着项目的不断升级&＃xff0c;项目体量逐渐变大&＃xff0c;页面可能也变的越来越多&＃xff0c;然后我们希望能够在线上进行统计&＃xff0c;了解到具体哪些页面用户在进入时会出现卡顿&＃xff0c;布局文件加载也可能会导致卡顿。

常规方式&＃xff1a;覆写方法(setContentView)、手动埋点上报服务端&＃xff08;不够优雅&＃xff0c;代码具有侵入性&＃xff09;

AOP方式&＃xff1a;切Activity的setContentView&＃xff08;切面点&＃xff09;

&＃64; Around(“execution(*android.app.Activity.setContentView(…))”)

具体实现&＃xff1a;

&＃64;Around("execution(* android.app.Activity.setContentView(..))") public void getSetContentViewTime(ProceedingJoinPoint joinPoint) Signature signature &＃61; joinPoint.getSignature(); String name &＃61; signature.toShortString(); long time &＃61; System.currentTimeMillis(); try joinPoint.proceed(); catch (Throwable throwable) throwable.printStackTrace(); Log.i(name, " cost " &＃43; (System.currentTimeMillis() - time));

结果如下&＃xff1a;

思考&＃xff1a;如何获取每一个控件加载耗时&＃xff1f;

我们在上面使用setContentView获取到的是页面中所有控件的耗时情况&＃xff0c;那现在我想要知道这个页面中各个控件的耗时分布情况&＃xff0c;以便于整体的把控分析并且可以对耗时较多的控件做针对性的优化&＃xff0c;这样一个场景该如何实现呢&＃xff1f;由于每个页面布局中的控件都是不可控的&＃xff0c;有可能多也有可能少&＃xff0c;所以我们应该尽量做到低侵入性&＃xff0c;这个问题大家可以好好想想&＃xff0c;看看有什么解决方案。

解决方案&＃xff1a;使用LayoutInflaterCompat.Factory2&＃xff08;LayoutInflaterCompat是LayoutInflater的兼容类&＃xff09;让它在创建View时进行Hook&＃xff1a;

LayoutInflaterCompat.setFactory2(getLayoutInflater(), new LayoutInflater.Factory2() &＃64;Override public View onCreateView(View parent, String name, Context context, AttributeSet attrs) long time &＃61; System.currentTimeMillis(); View view &＃61; getDelegate().createView(parent, name, context, attrs); Log.i(name,"控件耗时&＃xff1a;" &＃43; (System.currentTimeMillis() - time)); return view; &＃64;Override public View onCreateView(String name, Context context, AttributeSet attrs) return null; );

结果如下&＃xff1a;可以看到我们确实获取到了列表Item中的每个控件的耗时情况

四、异步Inflate实战

在上面我们已经说过了布局文件加载慢主要的原因是有以下两点&＃xff1a;

布局文件读取慢&＃xff1a;IO过程
创建View慢&＃xff1a;通过反射创建一个对象比直接new一个对象要慢3倍&＃xff0c;布局嵌套层级复杂则反射更多

针对上面说的这两种情况&＃xff0c;相对应的解决套路也就是两种&＃xff1a;

根本性解决&＃xff1a;去掉IO过程、不使用反射
侧面缓解&＃xff1a;让主线程不耗时&＃xff0c;不影响主线程

这里针对侧面缓解的方案来介绍一种实现方式&＃xff1a;AsyncLayoutInflater&＃xff0c;谷歌提供的一个类&＃xff0c;简称异步Inflate

WorkThread加载布局&＃xff0c;原生是在UI Thread加载布局
加载完成之后回调主线程&＃xff0c;此时主线程拿到的是创建完成的View对象可以直接使用
节约主线程时间&＃xff0c;因为耗时是发生在了异步线程中&＃xff0c;主线程的响应能够得到保障

使用方式&＃xff1a;首先导入asynclayoutinflater的依赖库&＃xff0c;这里我们参考谷歌官方文档中androidx的使用&＃xff1a;

然后来修改我们的MainActivity中的onCreate()方法&＃xff1a;

&＃64;Override protected void onCreate(Bundle savedInstanceState) new AsyncLayoutInflater(this).inflate(R.layout.activity_main, null, new AsyncLayoutInflater.OnInflateFinishedListener() &＃64;Override public void onInflateFinished(&＃64;NonNull View view, int resid, &＃64;Nullable ViewGroup parent) setContentView(view); mRecycler &＃61; findViewById(R.id.mRecycler); mRecycler.setLayoutManager(new LinearLayoutManager(MainActivity.this)); mRecycler.addItemDecoration(new DividerItemDecoration(MainActivity.this, DividerItemDecoration.VERTICAL)); mRecycler.setAdapter(mAdapter); mAdapter.setOnFeedShowCallBack(MainActivity.this); ); super.onCreate(savedInstanceState); // setContentView(R.layout.activity_main); mAdapter &＃61; new FeedAdapter(this, mList); initData(); // getFPS();

有兴趣的可以去看一下AsyncLayoutInflater的源码&＃xff0c;理解起来应该不难&＃xff0c;这个类内部有一个Handler对象&＃xff0c;一个InflateThread类继承于Thread&＃xff0c;还有一个inflate方法&＃xff0c;该方法有三个入参resid、parent、callback&＃xff0c;同时将这三个参数封装成了InflateRequest的数据结构&＃xff0c;然后加到线程的队列中&＃xff0c;线程中同时有一个run()方法在不断执行&＃xff0c;它会从队列中取出一条InflateRequest&＃xff0c;然后这个request.inflate开始执行inflate()方法并返回request.view&＃xff0c;这个方法是执行在子线程中的&＃xff0c;最后通过Handler将它回调到主线程中&＃xff0c;同时有一个相关联的Callback&＃xff0c;在Callback中进行判断如果没有创建完成的话&＃xff0c;会回退到主线程中进行布局的加载&＃xff0c;最后将request.view回调到onInflateFinished()方法中&＃xff0c;这样主线程就可以在该方法中拿到对应的view了。

总结&＃xff1a;

不能设置LayoutInflater.Factory()&＃xff0c;需要自定义AsyncLayoutInflater解决&＃xff1b;
注意View中不能有依赖主线程的操作

五、X2C框架使用

上面这一部分是介绍了一种侧面缓解的方式&＃xff0c;那这一部分我们来思考一下从根本上解决该如何实现&＃xff1f;

首先来说一下思路哈&＃xff0c;其实也没啥思路&＃xff0c;就是利用Java代码写布局&＃xff0c;这种方案的特点如下&＃xff1a;

本质上解决了性能问题&＃xff08;没有xml文件也就没有了IO的过程&＃xff0c;直接new对象没有了反射的过程&＃xff09;
引入新问题&＃xff1a;不便于开发、可维护性差

思路有了但是看着实现起来却不太现实哈&＃xff0c;那咋办呢&＃xff1f;咋办呢&＃xff1f;咋办呢&＃xff1f;嗯&＃xff0c;这样拌&＃xff0c;大神还是很多的&＃xff0c;我们使用开源方案X2C&＃xff1a;

X2C框架介绍&＃xff1a;保留XML优点&＃xff0c;解决其性能问题

开发人员写XML&＃xff0c;加载Java代码
原理&＃xff1a;APT编译期翻译XML为Java代码

X2C框架的使用方式&＃xff1a;

添加依赖&＃xff1a;app/build.gradle中添加

annotationProcessor &＃39;com.zhangyue.we:x2c-apt:1.1.2&＃39; implementation &＃39;com.zhangyue.we:x2c-lib:1.0.6&＃39;

添加注解&＃xff1a;在使用布局的任意java类或方法上面添加&＃xff1a;

&＃64;Xml(layouts &＃61; "activity_main")

代码实战

将原有的setContentView注释掉&＃xff0c;然后使用X2C.setContentView()来设置布局&＃xff0c;运行之后发现是可以正常加载的&＃xff0c;图中左侧圈出来的是使用X2C编译之后的产物&＃xff0c;这个其实就是它的底层实现原理了&＃xff0c;我们来看一下&＃xff1a;

首先是布局文件&＃xff1a;

android:layout_width&＃61;"match_parent" android:layout_height&＃61;"match_parent" android:orientation&＃61;"vertical"> android:id&＃61;"&＃64;&＃43;id/mRecycler" android:layout_width&＃61;"match_parent" android:layout_height&＃61;"match_parent" />

然后是编译之后的代码&＃xff1a;

public class X2C0_Activity_Main implements IViewCreator &＃64;Override public View createView(Context ctx) Resources res &＃61; ctx.getResources(); LinearLayout linearLayout0 &＃61; new LinearLayout(ctx); linearLayout0.setOrientation(LinearLayout.VERTICAL); RecyclerView recyclerView1 &＃61; new RecyclerView(ctx); LinearLayout.LayoutParams layoutParam1 &＃61; new LinearLayout.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT,ViewGroup.LayoutParams.MATCH_PARENT); recyclerView1.setId(R.id.mRecycler); recyclerView1.setLayoutParams(layoutParam1); linearLayout0.addView(recyclerView1); return linearLayout0;

可以看到它内部就是将我们布局文件中的控件全都以Java对象的形式给new出来了。

X2C存在的问题&＃xff1a;

XML中有的部分属性Java不支持&＃xff08;虽然不多但是也有&＃xff09;
失去了系统的兼容&＃xff08;AppCompat&＃xff0c;如果你需要使用AppCompatXXX下面的控件可以通过修改X2C源码来定制化实现相关功能&＃xff09;

六、视图绘制优化

1.视图绘制流程

测量&＃xff1a;确定大小&＃xff08;自顶向下进行视图树的遍历&＃xff0c;确定ViewGroup和View应该有多大&＃xff09;
布局&＃xff1a;确定位置&＃xff08;执行另一个自顶向下的遍历操作&＃xff0c;ViewGroup会根据测量阶段测定的大小确定自己应该摆放的位置&＃xff09;
绘制&＃xff1a;绘制视图&＃xff08;对于视图树中的每个对象系统都会为它创建一个Canvas对象&＃xff0c;然后向GPU发送一条绘制命令进行绘制&＃xff09;

可能存在的性能问题&＃xff1a;

每个阶段耗时
自顶而下的遍历&＃xff08;如果Layout层级比较深则遍历也是很耗时的&＃xff09;
触发多次&＃xff08;比如嵌套使用RelativeLayout有可能会导致绘制环节触发多次&＃xff09;

2.布局层级及复杂度

编写布局的准则&＃xff1a;减少View树层级

不嵌套使用RelativeLayout
不在嵌套的LinearLayout中使用weight
merge标签&＃xff1a;减少一个层级&＃xff0c;只能用于根View

这里推荐使用&＃xff1a;ConstraintLayout&＃xff0c;网上关于它有很多的文章&＃xff0c;后面我也准备专门写一篇它的使用总结

实现几乎完全扁平化布局
构建复杂布局性能更高
具有RelativeLayout和LinearLayout特性

3.过度绘制

一个像素最好只被绘制一次
调试GPU过度绘制
蓝色可接受

避免过度绘制方法&＃xff1a;

去掉多余背景色&＃xff0c;减少复杂shape使用
避免层级叠加
自定义View使用clipRect屏蔽被遮盖View绘制&＃xff08;当覆写onDraw()之后&＃xff0c;系统就无法知道View中各个元素的位置和层级关系&＃xff0c;就无法做自动优化&＃xff0c;即无法自动忽略绘制那些不可见的元素&＃xff09;

4.布局绘制的其它优化技巧

ViewStub&＃xff1a;高效占位符、延迟初始化&＃xff08;这个标签没有大小&＃xff0c;也没有绘制功能不参与measure和layout过程&＃xff0c;资源消耗非常低&＃xff0c;一般用于延迟初始化&＃xff09;
onDraw中避免&＃xff1a;创建大对象、耗时操作
TextView相关优化&＃xff08;setText显示静态文本&＃xff09;

作者&＃xff1a;小尘
链接&＃xff1a;https://juejin.cn/post/7126829631583289357

最后

如果想要成为架构师或想突破20~30K薪资范畴&＃xff0c;那就不要局限在编码&＃xff0c;业务&＃xff0c;要会选型、扩展&＃xff0c;提升编程思维。此外&＃xff0c;良好的职业规划也很重要&＃xff0c;学习的习惯很重要&＃xff0c;但是最重要的还是要能持之以恒&＃xff0c;任何不能坚持落实的计划都是空谈。

如果你没有方向&＃xff0c;这里给大家分享一套由阿里高级架构师编写的《Android八大模块进阶笔记》&＃xff0c;帮大家将杂乱、零散、碎片化的知识进行体系化的整理&＃xff0c;让大家系统而高效地掌握Android开发的各个知识点。

相对于我们平时看的碎片化内容&＃xff0c;这份笔记的知识点更系统化&＃xff0c;更容易理解和记忆&＃xff0c;是严格按照知识体系编排的。

一、架构师筑基必备技能

1、深入理解Java泛型
2、注解深入浅出
3、并发编程
4、数据传输与序列化
5、Java虚拟机原理
6、高效IO
……

二、Android百大框架源码解析

1.Retrofit 2.0源码解析
2.Okhttp3源码解析
3.ButterKnife源码解析
4.MPAndroidChart 源码解析
5.Glide源码解析
6.Leakcanary 源码解析
7.Universal-lmage-Loader源码解析
8.EventBus 3.0源码解析
9.zxing源码分析
10.Picasso源码解析
11.LottieAndroid使用详解及源码解析
12.Fresco 源码分析——图片加载流程

三、Android性能优化实战解析

腾讯Bugly:对字符串匹配算法的一点理解
爱奇艺&＃xff1a;安卓APP崩溃捕获方案——xCrash
字节跳动&＃xff1a;深入理解Gradle框架之一&＃xff1a;Plugin, Extension, buildSrc
百度APP技术&＃xff1a;Android H5首屏优化实践
支付宝客户端架构解析&＃xff1a;Android 客户端启动速度优化之「垃圾回收」
携程&＃xff1a;从智行 Android 项目看组件化架构实践
网易新闻构建优化&＃xff1a;如何让你的构建速度“势如闪电”&＃xff1f;
…

四、高级kotlin强化实战

1、Kotlin入门教程
2、Kotlin 实战避坑指南
3、项目实战《Kotlin Jetpack 实战》

从一个膜拜大神的 Demo 开始
Kotlin 写 Gradle 脚本是一种什么体验&＃xff1f;
Kotlin 编程的三重境界
Kotlin 高阶函数
Kotlin 泛型
Kotlin 扩展
Kotlin 委托
协程“不为人知”的调试技巧
图解协程&＃xff1a;suspend

五、Android高级UI开源框架进阶解密

1.SmartRefreshLayout的使用
2.Android之PullToRefresh控件源码解析
3.Android-PullToRefresh下拉刷新库基本用法
4.LoadSir-高效易用的加载反馈页管理框架
5.Android通用LoadingView加载框架详解
6.MPAndroidChart实现LineChart&＃xff08;折线图&＃xff09;
7.hellocharts-android使用指南
8.SmartTable使用指南
9.开源项目android-uitableview介绍
10.ExcelPanel 使用指南
11.Android开源项目SlidingMenu深切解析
12.MaterialDrawer使用指南

六、NDK模块开发

1、NDK 模块开发
2、JNI 模块
3、Native 开发工具
4、Linux 编程
5、底层图片处理
6、音视频开发
7、机器学习

七、Flutter技术进阶

1、Flutter跨平台开发概述
2、Windows中Flutter开发环境搭建
3、编写你的第一个Flutter APP
4、Flutter开发环境搭建和调试
5、Dart语法篇之基础语法(一)
6、Dart语法篇之集合的使用与源码解析(二)
7、Dart语法篇之集合操作符函数与源码分析(三)
…